Protocol state fuzzing of TLS implementations

We describe a largely automated and systematic analysis of TLS implementations by what we call ‘protocol state fuzzing’: we use state machine learning to infer state ma-chines from protocol implementations, using only black-box testing, and then inspect the inferred state machines to look for spurious behaviour which might be an indica-tion of flaws in the program logic. For detecting the pres-ence of spurious behaviour the approach is almost fully automatic: we automatically obtain state machines and any spurious behaviour is then trivial to see. Detecting whether the spurious behaviour introduces exploitable security weaknesses does require manual investigation. Still, we take the point of view that any spurious func-tionality in a security protocol implementation is danger-ous and should be removed. We analysed both server- and client-side implemen-tations with a test harness that supports several key ex-change algorithms and the option of client certificate au-thentication. We show that this approach can catch an interesting class of implementation flaws that is appar-ently common in security protocol implementations: in three of the TLS implementations analysed new security flaws were found (in GnuTLS, the Java Secure Socket Extension, and OpenSSL). This shows that protocol state fuzzing is a useful technique to systematically analyse security protocol implementations. As our analysis of different TLS implementations resulted in different and unique state machines for each one, the technique can also be used for fingerprinting TLS implementations.

Polymorphic Encryption and Pseudonymisation for Personalised Healthcare

Polymorphic encryption and Pseudonymisation, abbreviated as PEP, form a novel approach for the management of sensitive personal data, especially in health care. Traditional encryption is rather rigid: once encrypted, only one key can be used to decrypt the data. This rigidity is becoming an every greater problem in the context of big data analytics, where different parties who wish to investigate part of an encrypted data set all need the one key for decryption. Polymorphic encryption is a new cryptographic technique that solves these problems. Together with the associated technique of polymorphic pseudonymisation new security and privacy guarantees can be given which are essential in areas such as (personalised) healthcare, medical data collection via self-measurement apps, and more generally in privacy-friendly identity management and data analytics. The key ideas of polymorphic encryption are: 1. Directly after generation, data can be encrypted in a `polymorphic\u27 manner and stored at a (cloud) storage facility in such a way that the storage provider cannot get access. Crucially, there is no need to a priori fix who gets to see the data, so that the data can immediately be protected. For instance a PEP-enabled self-measurement device will store all its measurement data in polymorphically encrypted form in a back-end data base. 2. Later on it can be decided who can decrypt the data. This decision will be made on the basis of a policy, in which the data subject should play a key role. The user of the PEP-enabled device can, for instance, decide that doctors $X,Y,Z$ may at some stage decrypt to use the data in their diagnosis, or medical researcher groups $A, B, C$ may use it for their investigations, or third parties $U,V,W$ may use it for additional services, etc. 3. This `tweaking\u27 of the encrypted data to make it decryptable by a specific party can be done in a blind manner. It will have to be done by a trusted party who knows how to tweak the ciphertext for whom. This PEP technology can provide the necessary security and privacy infrastructure for big data analytics. People can entrust their data in polymorphically encrypted form, and each time decide later to make (parts of) it available (decryptable) for specific parties, for specific analysis purposes. In this way users remain in control, and can monitor which of their data is used where by whom for which purposes. The polymorphic encryption infrastructure can be supplemented with a pseudonymisation infrastructure which is also polymorphic, and guarantees that each individual will automatically have different pseudonyms at different parties and can only be de-pseudonymised by participants (like medical doctors) who know the original identity. This white paper provides an introduction to Polymorphic Encryption and Pseudonymisation (PEP), at different levels of abstraction, focusing on health care as application area. It contains a general description of PEP, explaining the basic functionality for laymen, supplemented by a clarification of the legal framework provided by the upcoming General Data Protection Regulation (GDPR) of the European Union. The paper also contains a more advanced, mathematically oriented description of PEP, including the underlying cryptographic primitives, key and pseudonym managment, interaction protocols, etc. This second part is aimed at readers with a background in computer security and cryptography. The cryptographic basis for PEP is ElGamal public key encryption, which is well-known since the mid 1980s. It is the way in which this encryption is used --- with re-randomisation, re-keying and re-shuffling --- that is new. The PEP framework is currently elaborated into an open design and open source (prototype) implementation at Radboud University in Nijmegen, The Netherlands. The technology will be used and tested in a real-life medical research project at the Radboud University Medical Center

Stacco: Differentially Analyzing Side-Channel Traces for Detecting SSL/TLS Vulnerabilities in Secure Enclaves

Intel Software Guard Extension (SGX) offers software applications enclave to protect their confidentiality and integrity from malicious operating systems. The SSL/TLS protocol, which is the de facto standard for protecting transport-layer network communications, has been broadly deployed for a secure communication channel. However, in this paper, we show that the marriage between SGX and SSL may not be smooth sailing. Particularly, we consider a category of side-channel attacks against SSL/TLS implementations in secure enclaves, which we call the control-flow inference attacks. In these attacks, the malicious operating system kernel may perform a powerful man-in-the-kernel attack to collect execution traces of the enclave programs at page, cacheline, or branch level, while positioning itself in the middle of the two communicating parties. At the center of our work is a differential analysis framework, dubbed Stacco, to dynamically analyze the SSL/TLS implementations and detect vulnerabilities that can be exploited as decryption oracles. Surprisingly, we found exploitable vulnerabilities in the latest versions of all the SSL/TLS libraries we have examined. To validate the detected vulnerabilities, we developed a man-in-the-kernel adversary to demonstrate Bleichenbacher attacks against the latest OpenSSL library running in the SGX enclave (with the help of Graphene) and completely broke the PreMasterSecret encrypted by a 4096-bit RSA public key with only 57286 queries. We also conducted CBC padding oracle attacks against the latest GnuTLS running in Graphene-SGX and an open-source SGX-implementation of mbedTLS (i.e., mbedTLS-SGX) that runs directly inside the enclave, and showed that it only needs 48388 and 25717 queries, respectively, to break one block of AES ciphertext. Empirical evaluation suggests these man-in-the-kernel attacks can be completed within 1 or 2 hours.Comment: CCS 17, October 30-November 3, 2017, Dallas, TX, US

Chromatic periodic activity down to 120 MHz in a Fast Radio Burst

Fast radio bursts (FRBs) are extragalactic astrophysical transients whose brightness requires emitters that are highly energetic, yet compact enough to produce the short, millisecond-duration bursts. FRBs have thus far been detected between 300 MHz and 8 GHz, but lower-frequency emission has remained elusive. A subset of FRBs is known to repeat, and one of those sources, FRB 20180916B, does so with a 16.3 day activity period. Using simultaneous Apertif and LOFAR data, we show that FRB 20180916B emits down to 120 MHz, and that its activity window is both narrower and earlier at higher frequencies. Binary wind interaction models predict a narrower periodic activity window at lower frequencies, which is the opposite of our observations. Our detections establish that low-frequency FRB emission can escape the local medium. For bursts of the same fluence, FRB 20180916B is more active below 200 MHz than at 1.4 GHz. Combining our results with previous upper-limits on the all-sky FRB rate at 150 MHz, we find that there are 3-450 FRBs/sky/day above 50 Jy ms at 90% confidence. We are able to rule out the scenario in which companion winds cause FRB periodicity. We also demonstrate that some FRBs live in clean environments that do not absorb or scatter low-frequency radiation.Comment: 50 pages, 14 figures, 3 tables, submitte